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Response to Arguments 

Applicant's arguments filed April 12, 2005 have been fiilly considered but they are not 
conpletely persuasive, because Applicant does not provide substantial information regarding to 
Examiner's questions as follows: 

Does Applicant locate and load any pixel data (computer instructions) id? 
Examiner's comment: The most common and well-known transfer function is the 
Laplace or Fourier transform of the impulse response function. The function of transfer 
function appHes directly to this invention, because the AppHcant uses this term to specify 
the mapping, writing, reading and performing of the addresses of pixel data. Examiner 
extracted the definition of the term "transfer function" from the authoritative dictionary 
of IEEE standards terms 7 edition on page 1 199 in the right column id. 
Does Applicant agree with the definition of the transfer function id? 
What type of transfer function is AppKcant claiming (the Laplace or Fourier transform) 

id? 

Applicant on page 7 of remarks/arguments does not argue, the only remark made by 
Applicant is on the same page, lines 6-8, quote "it is believed that the above-described 
amendments to claims 26, 38 and 50 also overcome the obviousness rejection under U.S.C. 
103(a)". 

Examiner's reply to Applicant's amendments: Not only Applicant makes the terminology 
free from doubt, but also added more confusing terms. 

e.g. in claim 26 Applicant amended reading as "using transformation engine and without 
using a fetch engine". Now referrmg to the specification on pages 2 and 3, lines 12-16, 14-19, 
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respectively, regarding the terminology of "transformation engines". The following quotes are 
copied and pasted from the specification: from page 2, (when multiple transformations are 
needed, the programmer must awkwardly impose the transformations by causing the fetch engine 
to manipulate the data between a memory location and the various transformation engines.) and 
from page 3, (the pixel data may be operated on by a plurality of transformation engines such as 
the scaling engine 100, the color conversion engine 106, and the conposition engine 104. To do 
so, a fetch engine (not shown) fetches the data from memory and passes it to a first 
transformation engine.). Examiner's comments: the specification does not support the claim 
language that Applicant uses. Examiner refers Applicant to Homan on page 136, left col under 
subject of "texture locaUty" at second paragraph teaches three factors affect the unique Texel to 
fragment ratio of a scene. It is very obvious that those data are considered as pixel data and 
plurality of steps can be considered as transformation engines as Applicant broadly discloses. 
Also in fig. 1 on page 134 of Homan illustrates different levels that each level can be considered 
as a transformation engine. 

Re. amendment in claims 36 and 48, the terminology "a second transformation" cannot be found 
in the specification. Examiner again refers to fig. 1 on page 134 of Homan that illustrates 
different levels that each level can be considered as a transformation engine (e.g. first 
transformation, second transformation, third . . . and so on). 

Re. the amendment of claim 38 id. And regarding the amendment in claims 50-53, the previous 
rejection still maintained. 
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Claim Rejections - 35 USC § 112 
The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and xjsing it, in such flill, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

Claims 26-54 rejected under 35 U.S.C. 112, first paragraph, as faihng to comply with the 
written description requirement. The claim(s) contains subject matter, which was not described 
in the specification in such a way as to reasonably convey to one skilled in the relevant art that 
the inventor(s), at the time the apphcation was filed, had possession of the claimed invention. 
Applicant claims that transferring pixel data at a given memory address range using 
transformation engine and without using a fetch engine. But appHcant does not specify, and it is 
not clear what type of algorithms or methods applicant uses. The following quotes are copied and 
pasted from the specification: from page 2, (when multiple transformations are needed, the 
programmer must awkwardly impose the transformations by causing the fetch engine to 
manipulate the data between a memory location and the various transformation engines.) and 
from page 3, (the pixel data may be operated on by a plurality of transformation engines such as 
the scaling engine 100, the color conversion engine 106, and the composition engine 104. To do 
so, a fetch engine (not shown) fetches the data from memory and passes it to a first 
transformation engine.). Examiner's comments: the specification does not support the claim 
language that AppUcant uses. 

Applicant in claims 36-37 and 48-49 claims a "second transformation" was not described in the 
specification. 
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The following is a quotation of the second paragraph of 35 U.S. C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

Claims 34, 35, 48-54 rejected under 35 U.S.C. 112, second paragraph, as being indefinite 
for failing to particularly point out and distinctly claim the subject matter which applicant 
regards as the invention. Applicant uses the term "TRANSFER FUNCTION" to specify the 
mapping, writing, reading, performing, and etc. of the addresses of pixel data. The transfer 
function in general terms can be written as a program or can be used as hardware. The definition 
of the transfer function: 1. A mathematical statement that describes the transfer characteristics of 
a system , subsystem, or equipment. 2. The relationship between the input and the output of a 
system, subsystem, or equipment in terms of the transfer characteristics. Therefore in respect to 
the definition the fetch engine is considered as a transfer function. 

Claim Rejections - 35 USC § 103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

Claims 26-54 rejected under 35 U.S.C. 103(a) as being unpatentable over Homan Igehy 
et al. (hereinafter referred as a Homan), R, Pendse and R. Bhagavathula (hereinafter referred as a 
Pendse), and further in view of Kajita. 
1. Claims 26-28. 
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A method conq)rismg: transferring pixel data to a transformation engine at a given memory 
address range; performing a transformation on the pixel data; and readdressing the transformed 
pixel data to another memory address range without using a fetch engine. Homan page 133 under 
subject of "mip mapping" teaches a transformation for each pixel data. Homan in fig. 3 
illustrates readdressing the transformed pixel data to another address range using the 
transformation engine and. Homan does not expUcitly specify the architecture for pixel data 
transformations without using a fetch engine. However Homan in fig. 6 illustrates a performance 
between architecture with no prefetching and with prefetching. Examiner's interpretation: no 
prefetch is equivalent to no fetch engine. Also Pendse teaches algorithm with pre- fetching. That 
is different fi'om fetch engine that apphcant claims. Homan and Pendse do not expUcitly specify 
readdressing, writing, performing the transformed graphical data to another memory address 
range as Applicant claimed iii the claim 1, however Kajita in col. 2, lines 1-19 teaches a step of 
accessing the physical memory by using a second address space; an address conversion step of 
performing mapping and management of address data fi:'om the first address space to the second 
address space in unit of a predetermined memory block. And also Kajita is silent about using the 
fetch engine. Thus, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to incorporate the teaching of Kajita (i.e. combines the extracted page frame 
number with offset data stored in the first address space to map address data to the second 
address space in unit of the memory block) and Pendse (i.e. teaches a S-LRU algorithm with pre- 
fetching and generating a virtual memory by dividing the cache into two segments) into Homan 
invention to improve the latency problem in caching and prefetching architecture. This 
modification would be beneficial to users working with graphics. 
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2. Claim 29. 

The method of claim 28 further including: generating a virtual memory address for a second 
memory location. Pendse on page 863 in left column teaches a S-LRU algorithm with pre- 
fetching. Generating a virtual memory by dividing the cache into two segments. 

3. Claim 30. 

The method of claim 29 further including: re-mapping a virtual memory address of said first 
virtual memory location to write said transformed pixel data from said first virtual memory 
location to said virtual memory address of said second memory location; and transferring the 
pixel data to a memory controller using a memory controller cUent in a forward, write-through 
direction. The step of re-mapping is obvious because when the cache is divided into two 
segments, the memory addresses of first and second locations must be known in order to be able 
to transform the graphical data within the memory locations. Pendse on page 863 in left column 
teaches a S-LRU algorithm with pre- fetching. Generating a virtual memory by dividing the cache 
into two segments. 

4. Claim 31. 

The method of claim 30 further including writing pixel data to a virtual memory location 
associated with a memory controller client that receives pixel data written to certain virtual 
addresses. Homan in fig. 2 illustrates a texture memory system, recorder buffer and cache, which 
can be considered as virtual addresses. 

5. Claim 32. 



Application/Control Number: 09/584,604 Page 8 

Art Unit: 2672 

The method of claim 3 1 including causing an operating system to set aside virtual addresses for 
said memory controller client. Kajita in fig. 3 illustrates virtual addresses and it is obvious to set 
aside addresses by operating system 

6. Claim 33. 

The method of claim 30 wherein generating said virtual memory address for said second memory 
location includes transforming the addresses of said pixel data at said first virtual memory 
location to addresses at said second memory location. Pendse on page 863 in left column teaches 
a S-LRU algorithm with pre-fetching. Generating a virtual memory by dividing the cache into 
two segments. 

7. Claim 34. 

The method of claim 33 including determining the offset to pixel data by subtracting a base 
address at said first virtual memory location from the address of pixel data. The step is obvious 
because Kajita teaches in col. 4, lines 34-36, the acquired PFN is combined with the OFFSET of 
the original virtual address, thereby converted to a physical address, and outputted. 

8. Claim 35. 

The method of claim 34 including adding said offset to a base address of said second memory 
location. Kajita teaches in the address conversion step, a corresponding page frame number is 
extracted from an associative memory based on a virtual page number stored in the first address 
space, and the extracted page frame number is combined with offset data stored in the first 
address space to map address data to the second address space in unit of the memory block. 

9. Claims 36 and 48. 
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The method of claim 30 wherein writing said transformed pixel data from said first virtual 
memory location to said second memory location includes writing the pixel data from said first 
virtual memory location associated with a first transfer function that performs a second 
transformation on the transformed pixel data to said second memory location associated with a 
second transfer fiinction that performs a second transformation on the transformed pixel data. 
The step is obvious because of the broad claim language "transfer function", it is well known in 
the art that a pipeline supports block moves, block reads and write operations, as well as other 
data transfer functions in hardware and software. Pendse on page 863 in left column teaches a S- 
LRU algorithm with pre- fetching. Generating a virtual memory by dividing the cache into two 
segments 

10, Claim 37. 

The method of claim 36 including transforming the addresses of the pixel data from addresses in 
a first virtual memory range associated with said first transfer function to memory addresses in a 
second virtual memory range associated with said second transfer function. Pendse on page 863 
in left column teaches a S-LRU algorithm with pre-fetching. Generating a virtual memory by 
dividing the cache into two segments 

11. Claim 38. 

See rejection of claim 26. An article conprising a medium storing instructions that enable a 
processor-based system to: transfer pixel data to a transformation engine at a given memory 
address range; perform a transformation on the pixel data; and readdress the transformed pixel 
data to another memory address range using the transform engine and without using a fetch 
engine. 
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12. Claim 39. 

See rejection of claim 26. The article of claim 38 further storing instructions that enable the 
processor-based system to: manipulate the transformed pixel data without going between a 
memory location and another transformation engine. 

13. Claim 40. 

See rejection of claim 26. The article of claim 39 further storing instructions that enable the 
processor-based system to: write pixel data to a first virtual memory location; and perform a first 
pixel transformation at said first virtual memory location in a virtual memory space. 

14. Claim 41. 

See rejection of claim 29, The article of claim 40 further storing instructions that enable the 
processor-based system to: generate a virtual memory address for a second memory location. 

15. Claim 42. 

See rejection of claim 30, The article of claim 41 further storing instructions that enable the 
processor-based system to: re-map a virtual memory address of said first virtual memory location 
to write said transformed pixel data from said first virtual memory location to said virtual 
memory address of said second memory location; and transfer the pixel data to a memory 
controller using a memory controller client in a forward write-through direction. 

16. Claim 43. 

See rejection of claim 31, The article of claim 42 further storing instructions that enable the 
processor-based system to write pixel data to a virtual memory location associated with a 
memory controller client that receives pixel data written to certain virtual addresses. 

17. Claim 44. 
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See rejection of claim 32. The article of claim 43 further storing instructions that enable the 
processor-based system to cause an operating system to set aside virtual addresses for said 
memory controller cUent. 

18. Claim 45. 

See rejection of claim 33. The article of claim 42 further storing instructions that enable the 
processor-based system to transform the addresses of pixel data at said first virtual memory 
location to addresses at said second memory location. 

19. Claim 46. 

See rejection of claim 34. The article of claim 45 further storing instructions that enable the 
processor-based system to determine the offset to each pixel data by subtracting a base address at 
said first virtual memory location from the address of each pixel data. 

20. Claim 47. 

See rejection of claim 35. The article of claim 46 further storing instructions that enable the 
processor-based system to add said offset to a base address of said second memory location. 

21. Claim 49. 

See rejection of claim 37. The article of claim 48 further storing instructions that enable the 
processor-based system to transform the addresses of said pixel data from addresses in a first 
virtual memory range associated with said first transfer function to memory addresses in a 
second virtual memory range associated with said second transfer function. 

22. Claim 50. 

See rejection of claim 26. A system comprising: a memory controller to receive pixel data and 
virtual memory addresses for a transformation of the pixel data in a virtual memory space; a first 
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memory controller client to forward the pixel data and virtual memory addresses to a first 
transfer function to perform the transformation of the pixel data; and a second memory controller 
chent to receive data from said first transfer function together with new virtual memory 
addresses for transfer in a forward, write-through direction without using a fetch engine. 

23. Claim 51. 

See rejection of claim 26. The system of claim 50 wherein said first memory controller client is 
toselectively forward the pixel data and virtual memory addresses to one of a plurality of transfer 
functions and said second memory controller chent is to receive the pixel data with new virtual 
memory addresses from said plurality of transfer functions. 

24. Claim 52. 

See rejection of claim 31. The system of claim 51 wherein said second memory controller chent 
is to write the pixel data back to said memory controller. 

25. Claim 53. 

See rejection of claim 26. The system of claim 50 including a plurality of transfer functions to 
perform transformation on the pixel data, one of said transfer functions arranged to write output 
data to an address range of another of said transfer functions. 

26. Claim 54. 

See rejection of claim 37. The system of claim 53 wherein said transfer functions are associated 
with virtual memory address ranges. 
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Conclusion 

Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, TfflS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time poUcy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 . 136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Javid A. Amini whose telephone number is 571-272-7654. The 
examiner can normally be reached on 8-4pni 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Michael Razavi can be reached on 571-272-7664. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 



Application/Control Number: 09/584,604 



Page 14 



Art Unit: 2672 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system Status information for published appUcations 
may be obtained from either Private PAIR or PubUc PAIR. Status information for unpublished 
apphcations is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 




Javid Amini 



